fix: resolve symlinks in runtime bin scripts - #43

Review on ArchCode

Problem and author intent

Global npm installations (npm install -g @archastro/redline) create symbolic links in the environment's bin directory pointing to node_modules/@archastro/redline/runtime/bin/*. redline-sidecar was previously updated with a readlink loop to resolve symlinks before deriving its $HERE path, but redline-pull, redline-watch, and redline-tail still used $(dirname "$0")/... When executed via global PATH symlinks, this evaluated to the parent of the bin folder (e.g. the Node installation root) rather than the package root, crashing with MODULE_NOT_FOUND for lib/cli-http.js.

The author intent is to ensure all global CLI binaries resolve symlinks to their canonical package location so that end-users and agent skills invoking redline-pull can communicate with the local helper daemon without path resolution failures.

What changed

• Added POSIX symlink resolution loops (while [ -L "$SCRIPT" ]) to runtime/bin/redline-pull, runtime/bin/redline-watch, and runtime/bin/redline-tail.
• Added automated regression testing in tests/cli-auth.test.js validating that redline-pull, redline-tail, redline-sidecar, and redline-clear execute cleanly when invoked through symbolic links.
• Added patch changeset .changeset/fix-cli-symlink-resolution.md.

Scope indicator

Backend / CLI / tooling only. The Chrome Web Store extension code is completely untouched.

Risk assessment

Low. Reuses the exact symlink resolution pattern already proven and tested in redline-sidecar.

User impact

Users who install @archastro/redline globally can now invoke redline-pull, redline-watch, and redline-tail directly from their terminal or coding agents without hitting module loading errors.

Testing

• Automated test: tests/cli-auth.test.js -> runtime bin scripts resolve module paths when invoked via symlinks passes.
• Full unit and integration test suite: 395/395 tests passing.
• npm run check:syntax, npm run check:versions, and npm pack --dry-run all pass.